Autogenerated HTML docs for v1.7.1-524-g6df2
diff --git a/RelNotes-1.7.1.1.txt b/RelNotes-1.7.1.1.txt index 2eef038..e0386a4 100644 --- a/RelNotes-1.7.1.1.txt +++ b/RelNotes-1.7.1.1.txt
@@ -15,14 +15,31 @@ macro that set/unset one attribute, immediately followed by an overriding setting; this makes attribute macros much easier to use. + * We didn't recognize timezone "Z" as a synonym for "UTC" (75b37e70). + * "git am -3" did not show diagnosis when the patch in the message was corrupt. + * After "git apply --whitespace=fix" removed trailing blank lines in an + patch in a patch series, it failed to apply later patches that depend + on the presense of such blank lines. + * "git bundle --stdin" segfaulted. + * "git checkout" and "git rebase" overwrote paths that are marked "assume + unchanged". + * "git describe" did not tie-break tags that point at the same commit correctly; newer ones are preferred by paying attention to the tagger date now. + * "git diff" used to tell underlying xdiff machinery to work very hard to + minimize the output, but this often was spending too many extra cycles + for very little gain. + + * "git diff --color" did not paint extended diff headers per line + (i.e. the coloring escape sequence didn't end at the end of line), + which confused "less -R". + * "git fetch" over HTTP verifies the downloaded packfiles more robustly. * The memory usage by "git index-pack" (run during "git fetch" and "git @@ -32,6 +49,10 @@ * "git log --abbrev=$num --format='%h' ignored --abbrev=$num. + * "git pull" accepted "--dry-run", gave it to underlying "git fetch" but + ignored the option itself, resulting in a bogus attempt to merge + unrelated commit. + * "git send-email" lacked a way to specify the domainname used in the EHLO/HELO exchange, causing rejected connection from picky servers. It learned --smtp-domain option to solve this issue.
diff --git a/RelNotes-1.7.2.txt b/RelNotes-1.7.2.txt index bd87a91..a1b5428 100644 --- a/RelNotes-1.7.2.txt +++ b/RelNotes-1.7.2.txt
@@ -19,10 +19,6 @@ * "git" wrapper learned "-c name=value" option to override configuration variable from the command line. - * After "git apply --whitespace=fix" removed trailing blank lines in an - patch in a patch series, it failed to apply later patches that depend - on the presense of such blank lines. - * The message from "git am -3" has been improved when conflict resolution ended up making the patch a no-op. @@ -39,10 +35,6 @@ * The output from the textconv filter used by "git diff" can be cached to speed up their reuse. - * "git diff --color" did not paint extended diff headers per line - (i.e. the coloring escape sequence didn't end at the end of line), - which confused "less -R". - * "git diff --word-diff=<mode>" extends the existing "--color-words" option, making it more useful in color-challenged environments. @@ -90,14 +82,9 @@ All of the fixes in v1.7.1.X maintenance series are included in this release, unless otherwise noted. - * We didn't recognize timezone "Z" as a synonym for "UTC" (75b37e70). - * We didn't URL decode "file:///path/to/repo" correctly when path/to/repo had percent-encoded characters (638794c, 9d2e942). - * "git checkout" and "git rebase" overwrote paths that are marked "assume - unchanged" (aecda37c). - * "git clone/fetch/pull" issued an incorrect error message when a ref and a symref that points to the ref were updated at the same time. This obviously would update them to the same value, and should not result in @@ -106,10 +93,6 @@ * "git clone" did not configure remote.origin.url correctly for bare clones (df61c889). - * "git diff" used to tell underlying xdiff machinery to work very hard to - minimize the output, but this often was spending too many extra cycles - for very little gain (582aa00). - * "git diff --graph" works better with "--color-words" and other options (81fa024..4297c0a). @@ -119,10 +102,6 @@ * "git merge --log" used to replace the custom message given by "-m" with the shortlog, instead of appending to it (tc/merge-m-log). - * "git pull" accepted "--dry-run", gave it to underlying "git fetch" but - ignored the option itself, resulting in a bogus attempt to merge - unrelated commit (29609e68). - * "git reset --hard" started from a wrong directory and a working tree in a nonstandard location is in use got confused (560fb6a1).
diff --git a/config.txt b/config.txt index 7afd0a3..9f1c785 100644 --- a/config.txt +++ b/config.txt
@@ -196,20 +196,17 @@ quoted without `-z` regardless of the setting of this variable. -core.autocrlf:: - If true, makes git convert `CRLF` at the end of lines in text files to - `LF` when reading from the work tree, and convert in reverse when - writing to the work tree. The variable can be set to - 'input', in which case the conversion happens only while - reading from the work tree but files are written out to the work - tree with `LF` at the end of lines. A file is considered - "text" (i.e. be subjected to the autocrlf mechanism) based on - the file's `crlf` attribute, or if `crlf` is unspecified, - based on the file's contents. See linkgit:gitattributes[5]. +core.eol:: + Sets the line ending type to use in the working directory for + files that have the `text` property set. Alternatives are + 'lf', 'crlf' and 'native', which uses the platform's native + line ending. The default value is `native`. See + linkgit:gitattributes[5] for more information on end-of-line + conversion. core.safecrlf:: - If true, makes git check if converting `CRLF` as controlled by - `core.autocrlf` is reversible. Git will verify if a command + If true, makes git check if converting `CRLF` is reversible when + end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If @@ -219,7 +216,7 @@ irreversible conversion but continue the operation. + CRLF conversion bears a slight chance of corrupting data. -autocrlf=true will convert CRLF to LF during commit and LF to +When it is enabled, git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings @@ -243,15 +240,25 @@ + Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of -`core.autocrlf`, but only for the current one. For example, a text -file with `LF` would be accepted with `core.autocrlf=input` and could -later be checked out with `core.autocrlf=true`, in which case the +`core.eol` and `core.autocrlf`, but only for the current one. For +example, a text file with `LF` would be accepted with `core.eol=lf` +and could later be checked out with `core.eol=crlf`, in which case the resulting file would contain `CRLF`, although the original file contained `LF`. However, in both work trees the line endings would be consistent, that is either all `LF` or all `CRLF`, but never mixed. A file with mixed line endings would be reported by the `core.safecrlf` mechanism. +core.autocrlf:: + Setting this variable to "true" is almost the same as setting + the `text` attribute to "auto" on all files except that text + files are not guaranteed to be normalized: files that contain + `CRLF` in the repository will not be touched. Use this + setting if you want to have `CRLF` line endings in your + working directory even though the repository does not have + normalized line endings. This variable can be set to 'input', + in which case no output conversion is performed. + core.symlinks:: If false, symbolic links are checked out as small plain files that contain the link text. linkgit:git-update-index[1] and @@ -979,13 +986,15 @@ various stuff. See linkgit:git-cvsserver[1]. gitcvs.usecrlfattr:: - If true, the server will look up the `crlf` attribute for - files to determine the '-k' modes to use. If `crlf` is set, - the '-k' mode will be left blank, so cvs clients will - treat it as text. If `crlf` is explicitly unset, the file + If true, the server will look up the end-of-line conversion + attributes for files to determine the '-k' modes to use. If + the attributes force git to treat a file as text, + the '-k' mode will be left blank so cvs clients will + treat it as text. If they suppress text conversion, the file will be set with '-kb' mode, which suppresses any newline munging - the client might otherwise do. If `crlf` is not specified, - then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5]. + the client might otherwise do. If the attributes do not allow + the file type to be determined, then 'gitcvs.allbinary' is + used. See linkgit:gitattributes[5]. gitcvs.allbinary:: This is used if 'gitcvs.usecrlfattr' does not resolve
diff --git a/git-checkout.html b/git-checkout.html index c32d65f..e7173dc 100644 --- a/git-checkout.html +++ b/git-checkout.html
@@ -328,29 +328,51 @@ </div> <h2 id="_description">DESCRIPTION</h2> <div class="sectionbody"> -<div class="para"><p>When <paths> are not given, this command switches branches by -updating the index, working tree, and HEAD to reflect the specified +<div class="para"><p>Updates files in the working tree to match the version in the index +or the specified tree. If no paths are given, <em>git checkout</em> will +also update <tt>HEAD</tt> to set the specified branch as the current branch.</p></div> -<div class="para"><p>If <tt>-b</tt> is given, a new branch is created and checked out, as if -<a href="git-branch.html">git-branch(1)</a> were called; in this case you can -use the --track or --no-track options, which will be passed to <tt>git -branch</tt>. As a convenience, --track without <tt>-b</tt> implies branch -creation; see the description of --track below.</p></div> -<div class="para"><p>When <paths> or --patch are given, this command does <strong>not</strong> switch -branches. It updates the named paths in the working tree from -the index file, or from a named <tree-ish> (most often a commit). In -this case, the <tt>-b</tt> and <tt>--track</tt> options are meaningless and giving -either of them results in an error. The <tree-ish> argument can be -used to specify a specific tree-ish (i.e. commit, tag or tree) -to update the index for the given paths before updating the -working tree.</p></div> -<div class="para"><p>The index may contain unmerged entries after a failed merge. By -default, if you try to check out such an entry from the index, the +<div class="vlist"><dl> +<dt> +<em>git checkout</em> [<branch>] +</dt> +<dt> +<em>git checkout</em> -b <new branch> [<start point>] +</dt> +<dd> +<p> + This form switches branches by updating the index, working + tree, and HEAD to reflect the specified branch. +</p> +<div class="para"><p>If <tt>-b</tt> is given, a new branch is created as if <a href="git-branch.html">git-branch(1)</a> +were called and then checked out; in this case you can +use the <tt>--track</tt> or <tt>--no-track</tt> options, which will be passed to +<em>git branch</em>. As a convenience, <tt>--track</tt> without <tt>-b</tt> implies branch +creation; see the description of <tt>--track</tt> below.</p></div> +</dd> +<dt> +<em>git checkout</em> [--patch] [<tree-ish>] [--] <pathspec>… +</dt> +<dd> +<p> + When <paths> or <tt>--patch</tt> are given, <em>git checkout</em> <strong>not</strong> switch + branches. It updates the named paths in the working tree from + the index file or from a named <tree-ish> (most often a commit). In + this case, the <tt>-b</tt> and <tt>--track</tt> options are meaningless and giving + either of them results in an error. The <tree-ish> argument can be + used to specify a specific tree-ish (i.e. commit, tag or tree) + to update the index for the given paths before updating the + working tree. +</p> +<div class="para"><p>The index may contain unmerged entries because of a previous failed merge. +By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. -Using -f will ignore these unmerged entries. The contents from a +Using <tt>-f</tt> will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by -using --ours or --theirs. With -m, changes made to the working tree -file can be discarded to recreate the original conflicted merge result.</p></div> +using <tt>--ours</tt> or <tt>--theirs</tt>. With <tt>-m</tt>, changes made to the working tree +file can be discarded to re-create the original conflicted merge result.</p></div> +</dd> +</dl></div> </div> <h2 id="_options">OPTIONS</h2> <div class="sectionbody"> @@ -446,21 +468,27 @@ </dt> <dd> <p> - Create a new branch named <new_branch>, unparented to any other - branch. The new branch you switch to does not have any commit - and after the first one it will become the root of a new history - completely unconnected from all the other branches. + Create a new <em>orphan</em> branch, named <new_branch>, started from + <start_point> and switch to it. The first commit made on this + new branch will have no parents and it will be the root of a new + history totally disconnected from all the other branches and + commits. </p> -<div class="para"><p>When you use "--orphan", the index and the working tree are kept intact. -This allows you to start a new history that records set of paths similar -to that of the start-point commit, which is useful when you want to keep -different branches for different audiences you are working to like when -you have an open source and commercial versions of a software, for example.</p></div> -<div class="para"><p>If you want to start a disconnected history that records set of paths -totally different from the original branch, you may want to first clear -the index and the working tree, by running "git rm -rf ." from the -top-level of the working tree, before preparing your files (by copying -from elsewhere, extracting a tarball, etc.) in the working tree.</p></div> +<div class="para"><p>The index and the working tree are adjusted as if you had previously run +"git checkout <start_point>". This allows you to start a new history +that records a set of paths similar to <start_point> by easily running +"git commit -a" to make the root commit.</p></div> +<div class="para"><p>This can be useful when you want to publish the tree from a commit +without exposing its full history. You might want to do this to publish +an open source branch of a project whose current tree is "clean", but +whose full history contains proprietary or otherwise encumbered bits of +code.</p></div> +<div class="para"><p>If you want to start a disconnected history that records a set of paths +that is totally different from the one of <start_point>, then you should +clear the index and the working tree right after creating the orphan +branch by running "git rm -rf ." from the top level of the working tree. +Afterwards you will be ready to prepare your new files, repopulating the +working tree, by copying them from elsewhere, extracting a tarball, etc.</p></div> </dd> <dt> -m @@ -699,7 +727,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-06-02 23:32:07 UTC +Last updated 2010-06-21 15:23:40 UTC </div> </div> </body>
diff --git a/git-checkout.txt b/git-checkout.txt index afda5c3..261dd90 100644 --- a/git-checkout.txt +++ b/git-checkout.txt
@@ -15,33 +15,41 @@ DESCRIPTION ----------- - -When <paths> are not given, this command switches branches by -updating the index, working tree, and HEAD to reflect the specified +Updates files in the working tree to match the version in the index +or the specified tree. If no paths are given, 'git checkout' will +also update `HEAD` to set the specified branch as the current branch. -If `-b` is given, a new branch is created and checked out, as if -linkgit:git-branch[1] were called; in this case you can -use the --track or --no-track options, which will be passed to `git -branch`. As a convenience, --track without `-b` implies branch -creation; see the description of --track below. +'git checkout' [<branch>]:: +'git checkout' -b <new branch> [<start point>]:: -When <paths> or --patch are given, this command does *not* switch -branches. It updates the named paths in the working tree from -the index file, or from a named <tree-ish> (most often a commit). In -this case, the `-b` and `--track` options are meaningless and giving -either of them results in an error. The <tree-ish> argument can be -used to specify a specific tree-ish (i.e. commit, tag or tree) -to update the index for the given paths before updating the -working tree. + This form switches branches by updating the index, working + tree, and HEAD to reflect the specified branch. ++ +If `-b` is given, a new branch is created as if linkgit:git-branch[1] +were called and then checked out; in this case you can +use the `--track` or `--no-track` options, which will be passed to +'git branch'. As a convenience, `--track` without `-b` implies branch +creation; see the description of `--track` below. -The index may contain unmerged entries after a failed merge. By -default, if you try to check out such an entry from the index, the +'git checkout' [--patch] [<tree-ish>] [--] <pathspec>...:: + + When <paths> or `--patch` are given, 'git checkout' *not* switch + branches. It updates the named paths in the working tree from + the index file or from a named <tree-ish> (most often a commit). In + this case, the `-b` and `--track` options are meaningless and giving + either of them results in an error. The <tree-ish> argument can be + used to specify a specific tree-ish (i.e. commit, tag or tree) + to update the index for the given paths before updating the + working tree. ++ +The index may contain unmerged entries because of a previous failed merge. +By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. -Using -f will ignore these unmerged entries. The contents from a +Using `-f` will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by -using --ours or --theirs. With -m, changes made to the working tree -file can be discarded to recreate the original conflicted merge result. +using `--ours` or `--theirs`. With `-m`, changes made to the working tree +file can be discarded to re-create the original conflicted merge result. OPTIONS ------- @@ -91,22 +99,29 @@ details. --orphan:: - Create a new branch named <new_branch>, unparented to any other - branch. The new branch you switch to does not have any commit - and after the first one it will become the root of a new history - completely unconnected from all the other branches. + Create a new 'orphan' branch, named <new_branch>, started from + <start_point> and switch to it. The first commit made on this + new branch will have no parents and it will be the root of a new + history totally disconnected from all the other branches and + commits. + -When you use "--orphan", the index and the working tree are kept intact. -This allows you to start a new history that records set of paths similar -to that of the start-point commit, which is useful when you want to keep -different branches for different audiences you are working to like when -you have an open source and commercial versions of a software, for example. +The index and the working tree are adjusted as if you had previously run +"git checkout <start_point>". This allows you to start a new history +that records a set of paths similar to <start_point> by easily running +"git commit -a" to make the root commit. + -If you want to start a disconnected history that records set of paths -totally different from the original branch, you may want to first clear -the index and the working tree, by running "git rm -rf ." from the -top-level of the working tree, before preparing your files (by copying -from elsewhere, extracting a tarball, etc.) in the working tree. +This can be useful when you want to publish the tree from a commit +without exposing its full history. You might want to do this to publish +an open source branch of a project whose current tree is "clean", but +whose full history contains proprietary or otherwise encumbered bits of +code. ++ +If you want to start a disconnected history that records a set of paths +that is totally different from the one of <start_point>, then you should +clear the index and the working tree right after creating the orphan +branch by running "git rm -rf ." from the top level of the working tree. +Afterwards you will be ready to prepare your new files, repopulating the +working tree, by copying them from elsewhere, extracting a tarball, etc. -m:: --merge::
diff --git a/git-config.html b/git-config.html index b9080c9..81819dc 100644 --- a/git-config.html +++ b/git-config.html
@@ -1035,19 +1035,16 @@ </p> </dd> <dt> -core.autocrlf +core.eol </dt> <dd> <p> - If true, makes git convert <tt>CRLF</tt> at the end of lines in text files to - <tt>LF</tt> when reading from the work tree, and convert in reverse when - writing to the work tree. The variable can be set to - <em>input</em>, in which case the conversion happens only while - reading from the work tree but files are written out to the work - tree with <tt>LF</tt> at the end of lines. A file is considered - "text" (i.e. be subjected to the autocrlf mechanism) based on - the file's <tt>crlf</tt> attribute, or if <tt>crlf</tt> is unspecified, - based on the file's contents. See <a href="gitattributes.html">gitattributes(5)</a>. + Sets the line ending type to use in the working directory for + files that have the <tt>text</tt> property set. Alternatives are + <em>lf</em>, <em>crlf</em> and <em>native</em>, which uses the platform's native + line ending. The default value is <tt>native</tt>. See + <a href="gitattributes.html">gitattributes(5)</a> for more information on end-of-line + conversion. </p> </dd> <dt> @@ -1055,8 +1052,8 @@ </dt> <dd> <p> - If true, makes git check if converting <tt>CRLF</tt> as controlled by - <tt>core.autocrlf</tt> is reversible. Git will verify if a command + If true, makes git check if converting <tt>CRLF</tt> is reversible when + end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If @@ -1066,7 +1063,7 @@ irreversible conversion but continue the operation. </p> <div class="para"><p>CRLF conversion bears a slight chance of corrupting data. -autocrlf=true will convert CRLF to LF during commit and LF to +When it is enabled, git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings @@ -1087,9 +1084,9 @@ converting CRLFs corrupts data.</p></div> <div class="para"><p>Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of -<tt>core.autocrlf</tt>, but only for the current one. For example, a text -file with <tt>LF</tt> would be accepted with <tt>core.autocrlf=input</tt> and could -later be checked out with <tt>core.autocrlf=true</tt>, in which case the +<tt>core.eol</tt> and <tt>core.autocrlf</tt>, but only for the current one. For +example, a text file with <tt>LF</tt> would be accepted with <tt>core.eol=lf</tt> +and could later be checked out with <tt>core.eol=crlf</tt>, in which case the resulting file would contain <tt>CRLF</tt>, although the original file contained <tt>LF</tt>. However, in both work trees the line endings would be consistent, that is either all <tt>LF</tt> or all <tt>CRLF</tt>, but never mixed. A @@ -1097,6 +1094,21 @@ mechanism.</p></div> </dd> <dt> +core.autocrlf +</dt> +<dd> +<p> + Setting this variable to "true" is almost the same as setting + the <tt>text</tt> attribute to "auto" on all files except that text + files are not guaranteed to be normalized: files that contain + <tt>CRLF</tt> in the repository will not be touched. Use this + setting if you want to have <tt>CRLF</tt> line endings in your + working directory even though the repository does not have + normalized line endings. This variable can be set to <em>input</em>, + in which case no output conversion is performed. +</p> +</dd> +<dt> core.symlinks </dt> <dd> @@ -2351,13 +2363,15 @@ </dt> <dd> <p> - If true, the server will look up the <tt>crlf</tt> attribute for - files to determine the <em>-k</em> modes to use. If <tt>crlf</tt> is set, - the <em>-k</em> mode will be left blank, so cvs clients will - treat it as text. If <tt>crlf</tt> is explicitly unset, the file + If true, the server will look up the end-of-line conversion + attributes for files to determine the <em>-k</em> modes to use. If + the attributes force git to treat a file as text, + the <em>-k</em> mode will be left blank so cvs clients will + treat it as text. If they suppress text conversion, the file will be set with <em>-kb</em> mode, which suppresses any newline munging - the client might otherwise do. If <tt>crlf</tt> is not specified, - then <em>gitcvs.allbinary</em> is used. See <a href="gitattributes.html">gitattributes(5)</a>. + the client might otherwise do. If the attributes do not allow + the file type to be determined, then <em>gitcvs.allbinary</em> is + used. See <a href="gitattributes.html">gitattributes(5)</a>. </p> </dd> <dt> @@ -3934,7 +3948,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-06-19 00:32:56 UTC +Last updated 2010-06-21 15:23:40 UTC </div> </div> </body>
diff --git a/git-cvsserver.html b/git-cvsserver.html index 0eb80de..a18daa3 100644 --- a/git-cvsserver.html +++ b/git-cvsserver.html
@@ -784,15 +784,12 @@ <div class="para"><p>By default the server leaves the <em>-k</em> mode blank for all files, which causes the cvs client to treat them as a text files, subject to crlf conversion on some platforms.</p></div> -<div class="para"><p>You can make the server use <tt>crlf</tt> attributes to set the <em>-k</em> modes -for files by setting the <tt>gitcvs.usecrlfattr</tt> config variable. -In this case, if <tt>crlf</tt> is explicitly unset (<em>-crlf</em>), then the -server will set <em>-kb</em> mode for binary files. If <tt>crlf</tt> is set, -then the <em>-k</em> mode will explicitly be left blank. See -also <a href="gitattributes.html">gitattributes(5)</a> for more information about the <tt>crlf</tt> -attribute.</p></div> +<div class="para"><p>You can make the server use the end-of-line conversion attributes to +set the <em>-k</em> modes for files by setting the <tt>gitcvs.usecrlfattr</tt> +config variable. See <a href="gitattributes.html">gitattributes(5)</a> for more information +about end-of-line conversion.</p></div> <div class="para"><p>Alternatively, if <tt>gitcvs.usecrlfattr</tt> config is not enabled -or if the <tt>crlf</tt> attribute is unspecified for a filename, then +or the attributes do not allow automatic detection for a filename, then the server uses the <tt>gitcvs.allbinary</tt> config for the default setting. If <tt>gitcvs.allbinary</tt> is set, then file not otherwise specified will default to <em>-kb</em> mode. Otherwise the <em>-k</em> mode @@ -835,7 +832,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-06-13 19:56:32 UTC +Last updated 2010-06-21 15:23:40 UTC </div> </div> </body>
diff --git a/git-cvsserver.txt b/git-cvsserver.txt index c27ca43..7004dd2 100644 --- a/git-cvsserver.txt +++ b/git-cvsserver.txt
@@ -369,16 +369,13 @@ which causes the cvs client to treat them as a text files, subject to crlf conversion on some platforms. -You can make the server use `crlf` attributes to set the '-k' modes -for files by setting the `gitcvs.usecrlfattr` config variable. -In this case, if `crlf` is explicitly unset ('-crlf'), then the -server will set '-kb' mode for binary files. If `crlf` is set, -then the '-k' mode will explicitly be left blank. See -also linkgit:gitattributes[5] for more information about the `crlf` -attribute. +You can make the server use the end-of-line conversion attributes to +set the '-k' modes for files by setting the `gitcvs.usecrlfattr` +config variable. See linkgit:gitattributes[5] for more information +about end-of-line conversion. Alternatively, if `gitcvs.usecrlfattr` config is not enabled -or if the `crlf` attribute is unspecified for a filename, then +or the attributes do not allow automatic detection for a filename, then the server uses the `gitcvs.allbinary` config for the default setting. If `gitcvs.allbinary` is set, then file not otherwise specified will default to '-kb' mode. Otherwise the '-k' mode diff --git a/git-rebase.html b/git-rebase.html index f0c80ca..644d172 100644 --- a/git-rebase.html +++ b/git-rebase.html
@@ -723,6 +723,9 @@ <p> Instead of ignoring merges, try to recreate them. </p> +<div class="para"><p>This uses the <tt>--interactive</tt> machinery internally, but combining it +with the <tt>--interactive</tt> option explicitly is generally not a good +idea unless you know what you are doing (see BUGS below).</p></div> </dd> <dt> --root @@ -1209,6 +1212,30 @@ <em>everyone</em> downstream from <em>topic</em> will now have to perform a "hard case" recovery too!</p></div> </div> +<h2 id="_bugs">BUGS</h2> +<div class="sectionbody"> +<div class="para"><p>The todo list presented by <tt>--preserve-merges --interactive</tt> does not +represent the topology of the revision graph. Editing commits and +rewording their commit messages should work fine, but attempts to +reorder commits tend to produce counterintuitive results.</p></div> +<div class="para"><p>For example, an attempt to rearrange</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>1 --- 2 --- 3 --- 4 --- 5</tt></pre> +</div></div> +<div class="para"><p>to</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>1 --- 2 --- 4 --- 3 --- 5</tt></pre> +</div></div> +<div class="para"><p>by moving the "pick 4" line will result in the following history:</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt> 3 + / +1 --- 2 --- 4 --- 5</tt></pre> +</div></div> +</div> <h2 id="_authors">Authors</h2> <div class="sectionbody"> <div class="para"><p>Written by Junio C Hamano <gitster@pobox.com> and @@ -1224,7 +1251,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-06-02 23:32:08 UTC +Last updated 2010-06-21 15:23:41 UTC </div> </div> </body>
diff --git a/git-rebase.txt b/git-rebase.txt index 50ba2e4..be23ad2 100644 --- a/git-rebase.txt +++ b/git-rebase.txt
@@ -310,6 +310,11 @@ -p:: --preserve-merges:: Instead of ignoring merges, try to recreate them. ++ +This uses the `--interactive` machinery internally, but combining it +with the `--interactive` option explicitly is generally not a good +idea unless you know what you are doing (see BUGS below). + --root:: Rebase all commits reachable from <branch>, instead of @@ -611,6 +616,28 @@ case" recovery too! +BUGS +---- +The todo list presented by `--preserve-merges --interactive` does not +represent the topology of the revision graph. Editing commits and +rewording their commit messages should work fine, but attempts to +reorder commits tend to produce counterintuitive results. + +For example, an attempt to rearrange +------------ +1 --- 2 --- 3 --- 4 --- 5 +------------ +to +------------ +1 --- 2 --- 4 --- 3 --- 5 +------------ +by moving the "pick 4" line will result in the following history: +------------ + 3 + / +1 --- 2 --- 4 --- 5 +------------ + Authors ------ Written by Junio C Hamano <gitster@pobox.com> and
diff --git a/gitattributes.html b/gitattributes.html index 761528f..e5abf0c 100644 --- a/gitattributes.html +++ b/gitattributes.html
@@ -410,18 +410,21 @@ such as <em>git checkout</em> and <em>git merge</em> run. They also affect how git stores the contents you prepare in the working tree in the repository upon <em>git add</em> and <em>git commit</em>.</p></div> -<h4 id="_tt_crlf_tt"><tt>crlf</tt></h4> -<div class="para"><p>This attribute controls the line-ending convention.</p></div> +<h4 id="_tt_text_tt"><tt>text</tt></h4> +<div class="para"><p>This attribute enables and controls end-of-line normalization. When a +text file is normalized, its line endings are converted to LF in the +repository. To control what line ending style is used in the working +directory, use the <tt>eol</tt> attribute for a single file and the +<tt>core.eol</tt> configuration variable for all text files.</p></div> <div class="vlist"><dl> <dt> Set </dt> <dd> <p> - Setting the <tt>crlf</tt> attribute on a path is meant to mark - the path as a "text" file. <em>core.autocrlf</em> conversion - takes place without guessing the content type by - inspection. + Setting the <tt>text</tt> attribute on a path enables end-of-line + normalization and marks the path as a text file. End-of-line + conversion takes place without guessing the content type. </p> </dd> <dt> @@ -429,43 +432,146 @@ </dt> <dd> <p> - Unsetting the <tt>crlf</tt> attribute on a path tells git not to + Unsetting the <tt>text</tt> attribute on a path tells git not to attempt any end-of-line conversion upon checkin or checkout. </p> </dd> <dt> +Set to string value "auto" +</dt> +<dd> +<p> + When <tt>text</tt> is set to "auto", the path is marked for automatic + end-of-line normalization. If git decides that the content is + text, its line endings are normalized to LF on checkin. +</p> +</dd> +<dt> Unspecified </dt> <dd> <p> - Unspecified <tt>crlf</tt> attribute tells git to apply the - <tt>core.autocrlf</tt> conversion when the file content looks - like text. -</p> -</dd> -<dt> -Set to string value "input" -</dt> -<dd> -<p> - This is similar to setting the attribute to <tt>true</tt>, but - also forces git to act as if <tt>core.autocrlf</tt> is set to - <tt>input</tt> for the path. + If the <tt>text</tt> attribute is unspecified, git uses the + <tt>core.autocrlf</tt> configuration variable to determine if the + file should be converted. </p> </dd> </dl></div> -<div class="para"><p>Any other value set to <tt>crlf</tt> attribute is ignored and git acts -as if the attribute is left unspecified.</p></div> -<h4 id="_the_tt_core_autocrlf_tt_conversion">The <tt>core.autocrlf</tt> conversion</h4> -<div class="para"><p>If the configuration variable <tt>core.autocrlf</tt> is false, no -conversion is done.</p></div> -<div class="para"><p>When <tt>core.autocrlf</tt> is true, it means that the platform wants -CRLF line endings for files in the working tree, and you want to -convert them back to the normal LF line endings when checking -in to the repository.</p></div> -<div class="para"><p>When <tt>core.autocrlf</tt> is set to "input", line endings are -converted to LF upon checkin, but there is no conversion done -upon checkout.</p></div> +<div class="para"><p>Any other value causes git to act as if <tt>text</tt> has been left +unspecified.</p></div> +<h4 id="_tt_eol_tt"><tt>eol</tt></h4> +<div class="para"><p>This attribute sets a specific line-ending style to be used in the +working directory. It enables end-of-line normalization without any +content checks, effectively setting the <tt>text</tt> attribute.</p></div> +<div class="vlist"><dl> +<dt> +Set to string value "crlf" +</dt> +<dd> +<p> + This setting forces git to normalize line endings for this + file on checkin and convert them to CRLF when the file is + checked out. +</p> +</dd> +<dt> +Set to string value "lf" +</dt> +<dd> +<p> + This setting forces git to normalize line endings to LF on + checkin and prevents conversion to CRLF when the file is + checked out. +</p> +</dd> +</dl></div> +<h4 id="_backwards_compatibility_with_tt_crlf_tt_attribute">Backwards compatibility with <tt>crlf</tt> attribute</h4> +<div class="para"><p>For backwards compatibility, the <tt>crlf</tt> attribute is interpreted as +follows:</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>crlf text +-crlf -text +crlf=input eol=lf</tt></pre> +</div></div> +<h4 id="_end_of_line_conversion">End-of-line conversion</h4> +<div class="para"><p>While git normally leaves file contents alone, it can be configured to +normalize line endings to LF in the repository and, optionally, to +convert them to CRLF when files are checked out.</p></div> +<div class="para"><p>Here is an example that will make git normalize .txt, .vcproj and .sh +files, ensure that .vcproj files have CRLF and .sh files have LF in +the working directory, and prevent .jpg files from being normalized +regardless of their content.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>*.txt text +*.vcproj eol=crlf +*.sh eol=lf +*.jpg -text</tt></pre> +</div></div> +<div class="para"><p>Other source code management systems normalize all text files in their +repositories, and there are two ways to enable similar automatic +normalization in git.</p></div> +<div class="para"><p>If you simply want to have CRLF line endings in your working directory +regardless of the repository you are working with, you can set the +config variable "core.autocrlf" without changing any attributes.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>[core] + autocrlf = true</tt></pre> +</div></div> +<div class="para"><p>This does not force normalization of all text files, but does ensure +that text files that you introduce to the repository have their line +endings normalized to LF when they are added, and that files that are +already normalized in the repository stay normalized.</p></div> +<div class="para"><p>If you want to interoperate with a source code management system that +enforces end-of-line normalization, or you simply want all text files +in your repository to be normalized, you should instead set the <tt>text</tt> +attribute to "auto" for _all_ files.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>* text=auto</tt></pre> +</div></div> +<div class="para"><p>This ensures that all files that git considers to be text will have +normalized (LF) line endings in the repository. The <tt>core.eol</tt> +configuration variable controls which line endings git will use for +normalized files in your working directory; the default is to use the +native line ending for your platform, or CRLF if <tt>core.autocrlf</tt> is +set.</p></div> +<div class="admonitionblock"> +<table><tr> +<td class="icon"> +<div class="title">Note</div> +</td> +<td class="content">When <tt>text=auto</tt> normalization is enabled in an existing +repository, any text files containing CRLFs should be normalized. If +they are not they will be normalized the next time someone tries to +change them, causing unfortunate misattribution. From a clean working +directory:</td> +</tr></table> +</div> +<div class="listingblock"> +<div class="content"> +<pre><tt>$ echo "* text=auto" >>.gitattributes +$ rm .git/index # Remove the index to force git to +$ git reset # re-scan the working directory +$ git status # Show files that will be normalized +$ git add -u +$ git add .gitattributes +$ git commit -m "Introduce end-of-line normalization"</tt></pre> +</div></div> +<div class="para"><p>If any files that should not be normalized show up in <em>git status</em>, +unset their <tt>text</tt> attribute before running <em>git add -u</em>.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>manual.pdf -text</tt></pre> +</div></div> +<div class="para"><p>Conversely, text files that git does not detect can have normalization +enabled manually.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>weirdchars.txt text</tt></pre> +</div></div> <div class="para"><p>If <tt>core.safecrlf</tt> is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of <tt>core.autocrlf</tt>. For "true", git rejects irreversible @@ -543,10 +649,10 @@ <div class="para"><p>In the check-in codepath, the worktree file is first converted with <tt>filter</tt> driver (if specified and corresponding driver defined), then the result is processed with <tt>ident</tt> (if -specified), and then finally with <tt>crlf</tt> (again, if specified +specified), and then finally with <tt>text</tt> (again, if specified and applicable).</p></div> <div class="para"><p>In the check-out codepath, the blob content is first converted -with <tt>crlf</tt>, and then <tt>ident</tt> and fed to <tt>filter</tt>.</p></div> +with <tt>text</tt>, and then <tt>ident</tt> and fed to <tt>filter</tt>.</p></div> <h3 id="_generating_diff_text">Generating diff text</h3><div style="clear:left"></div> <h4 id="_tt_diff_tt"><tt>diff</tt></h4> <div class="para"><p>The attribute <tt>diff</tt> affects how <em>git</em> generates diffs for particular @@ -991,7 +1097,7 @@ produced for, any binary file you track. You would need to specify e.g.</p></div> <div class="listingblock"> <div class="content"> -<pre><tt>*.jpg -crlf -diff</tt></pre> +<pre><tt>*.jpg -text -diff</tt></pre> </div></div> <div class="para"><p>but that may become cumbersome, when you have many attributes. Using attribute macros, you can specify groups of attributes set or unset at @@ -1002,7 +1108,7 @@ </div></div> <div class="para"><p>which is equivalent to the above. Note that the attribute macros can only be "Set" (see the above example that sets "binary" macro as if it were an -ordinary attribute --- setting it in turn unsets "crlf" and "diff").</p></div> +ordinary attribute --- setting it in turn unsets "text" and "diff").</p></div> </div> <h2 id="_defining_attribute_macros">DEFINING ATTRIBUTE MACROS</h2> <div class="sectionbody"> @@ -1011,7 +1117,7 @@ macro "binary" is equivalent to:</p></div> <div class="listingblock"> <div class="content"> -<pre><tt>[attr]binary -diff -crlf</tt></pre> +<pre><tt>[attr]binary -diff -text</tt></pre> </div></div> </div> <h2 id="_example">EXAMPLE</h2> @@ -1076,7 +1182,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-05-21 14:57:20 UTC +Last updated 2010-06-21 15:23:42 UTC </div> </div> </body>
diff --git a/gitattributes.txt b/gitattributes.txt index 0523a57..564586b 100644 --- a/gitattributes.txt +++ b/gitattributes.txt
@@ -92,53 +92,154 @@ git stores the contents you prepare in the working tree in the repository upon 'git add' and 'git commit'. -`crlf` +`text` ^^^^^^ -This attribute controls the line-ending convention. +This attribute enables and controls end-of-line normalization. When a +text file is normalized, its line endings are converted to LF in the +repository. To control what line ending style is used in the working +directory, use the `eol` attribute for a single file and the +`core.eol` configuration variable for all text files. Set:: - Setting the `crlf` attribute on a path is meant to mark - the path as a "text" file. 'core.autocrlf' conversion - takes place without guessing the content type by - inspection. + Setting the `text` attribute on a path enables end-of-line + normalization and marks the path as a text file. End-of-line + conversion takes place without guessing the content type. Unset:: - Unsetting the `crlf` attribute on a path tells git not to + Unsetting the `text` attribute on a path tells git not to attempt any end-of-line conversion upon checkin or checkout. +Set to string value "auto":: + + When `text` is set to "auto", the path is marked for automatic + end-of-line normalization. If git decides that the content is + text, its line endings are normalized to LF on checkin. + Unspecified:: - Unspecified `crlf` attribute tells git to apply the - `core.autocrlf` conversion when the file content looks - like text. + If the `text` attribute is unspecified, git uses the + `core.autocrlf` configuration variable to determine if the + file should be converted. -Set to string value "input":: +Any other value causes git to act as if `text` has been left +unspecified. - This is similar to setting the attribute to `true`, but - also forces git to act as if `core.autocrlf` is set to - `input` for the path. +`eol` +^^^^^ -Any other value set to `crlf` attribute is ignored and git acts -as if the attribute is left unspecified. +This attribute sets a specific line-ending style to be used in the +working directory. It enables end-of-line normalization without any +content checks, effectively setting the `text` attribute. +Set to string value "crlf":: -The `core.autocrlf` conversion -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + This setting forces git to normalize line endings for this + file on checkin and convert them to CRLF when the file is + checked out. -If the configuration variable `core.autocrlf` is false, no -conversion is done. +Set to string value "lf":: -When `core.autocrlf` is true, it means that the platform wants -CRLF line endings for files in the working tree, and you want to -convert them back to the normal LF line endings when checking -in to the repository. + This setting forces git to normalize line endings to LF on + checkin and prevents conversion to CRLF when the file is + checked out. -When `core.autocrlf` is set to "input", line endings are -converted to LF upon checkin, but there is no conversion done -upon checkout. +Backwards compatibility with `crlf` attribute +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For backwards compatibility, the `crlf` attribute is interpreted as +follows: + +------------------------ +crlf text +-crlf -text +crlf=input eol=lf +------------------------ + +End-of-line conversion +^^^^^^^^^^^^^^^^^^^^^^ + +While git normally leaves file contents alone, it can be configured to +normalize line endings to LF in the repository and, optionally, to +convert them to CRLF when files are checked out. + +Here is an example that will make git normalize .txt, .vcproj and .sh +files, ensure that .vcproj files have CRLF and .sh files have LF in +the working directory, and prevent .jpg files from being normalized +regardless of their content. + +------------------------ +*.txt text +*.vcproj eol=crlf +*.sh eol=lf +*.jpg -text +------------------------ + +Other source code management systems normalize all text files in their +repositories, and there are two ways to enable similar automatic +normalization in git. + +If you simply want to have CRLF line endings in your working directory +regardless of the repository you are working with, you can set the +config variable "core.autocrlf" without changing any attributes. + +------------------------ +[core] + autocrlf = true +------------------------ + +This does not force normalization of all text files, but does ensure +that text files that you introduce to the repository have their line +endings normalized to LF when they are added, and that files that are +already normalized in the repository stay normalized. + +If you want to interoperate with a source code management system that +enforces end-of-line normalization, or you simply want all text files +in your repository to be normalized, you should instead set the `text` +attribute to "auto" for _all_ files. + +------------------------ +* text=auto +------------------------ + +This ensures that all files that git considers to be text will have +normalized (LF) line endings in the repository. The `core.eol` +configuration variable controls which line endings git will use for +normalized files in your working directory; the default is to use the +native line ending for your platform, or CRLF if `core.autocrlf` is +set. + +NOTE: When `text=auto` normalization is enabled in an existing +repository, any text files containing CRLFs should be normalized. If +they are not they will be normalized the next time someone tries to +change them, causing unfortunate misattribution. From a clean working +directory: + +------------------------------------------------- +$ echo "* text=auto" >>.gitattributes +$ rm .git/index # Remove the index to force git to +$ git reset # re-scan the working directory +$ git status # Show files that will be normalized +$ git add -u +$ git add .gitattributes +$ git commit -m "Introduce end-of-line normalization" +------------------------------------------------- + +If any files that should not be normalized show up in 'git status', +unset their `text` attribute before running 'git add -u'. + +------------------------ +manual.pdf -text +------------------------ + +Conversely, text files that git does not detect can have normalization +enabled manually. + +------------------------ +weirdchars.txt text +------------------------ If `core.safecrlf` is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of @@ -223,11 +324,11 @@ In the check-in codepath, the worktree file is first converted with `filter` driver (if specified and corresponding driver defined), then the result is processed with `ident` (if -specified), and then finally with `crlf` (again, if specified +specified), and then finally with `text` (again, if specified and applicable). In the check-out codepath, the blob content is first converted -with `crlf`, and then `ident` and fed to `filter`. +with `text`, and then `ident` and fed to `filter`. Generating diff text @@ -651,7 +752,7 @@ produced for, any binary file you track. You would need to specify e.g. ------------ -*.jpg -crlf -diff +*.jpg -text -diff ------------ but that may become cumbersome, when you have many attributes. Using @@ -664,7 +765,7 @@ which is equivalent to the above. Note that the attribute macros can only be "Set" (see the above example that sets "binary" macro as if it were an -ordinary attribute --- setting it in turn unsets "crlf" and "diff"). +ordinary attribute --- setting it in turn unsets "text" and "diff"). DEFINING ATTRIBUTE MACROS @@ -675,7 +776,7 @@ macro "binary" is equivalent to: ------------ -[attr]binary -diff -crlf +[attr]binary -diff -text ------------
diff --git a/technical/api-run-command.html b/technical/api-run-command.html index 957c2b1..8306e6e 100644 --- a/technical/api-run-command.html +++ b/technical/api-run-command.html
@@ -699,8 +699,9 @@ </li> </ol></div> <div class="para"><p>There are serious restrictions on what the asynchronous function can do -because this facility is implemented by a pipe to a forked process on -UNIX, but by a thread in the same address space on Windows:</p></div> +because this facility is implemented by a thread in the same address +space on most platforms (when pthreads is available), but by a pipe to +a forked process otherwise:</p></div> <div class="olist"><ol> <li> <p> @@ -719,7 +720,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-04-24 02:56:22 UTC +Last updated 2010-06-21 15:23:42 UTC </div> </div> </body>
diff --git a/technical/api-run-command.txt b/technical/api-run-command.txt index 44876fa..f18b4f4 100644 --- a/technical/api-run-command.txt +++ b/technical/api-run-command.txt
@@ -231,8 +231,9 @@ There are serious restrictions on what the asynchronous function can do -because this facility is implemented by a pipe to a forked process on -UNIX, but by a thread in the same address space on Windows: +because this facility is implemented by a thread in the same address +space on most platforms (when pthreads is available), but by a pipe to +a forked process otherwise: . It cannot change the program's state (global variables, environment, etc.) in a way that the caller notices; in other words, .in and .out
